The following use case provides a more detailed look into cube dimension assignment.
Scenario:The user wants to add a customer dimension in the Budget Scenario Type to expand the annual planning capabilities and include their top customers. Data has been loaded to Actual and a prior year Budget. This use case provides example configurations to display the recommended approach and common misconfigurations.
Role: Administrator, Developer
Benefits: Setting all unused dimension types to the Root dimension enables you to add dimensions to specific Scenario Types in the future. If this is not configured properly, the entire cube must abide by the updates to the (Default) Scenario Type.
Configuration 1: Recommended Configuration
When a cube is created, specific Scenario Types with dimension types set to (Use Default) should be updated to the Root dimension. This enables data model flexibility and expansion in the future. For this use case, the Scenario Types are set to the following recommended configuration:
-
In the (Default) Scenario Type, Entity and Scenario dimension types are assigned. All non-Data Unit dimension types are left at the Root dimension.
-
For all active Scenario Types, all non-Data Unit dimensions are assigned to a specific dimension. The Root dimension is selected for all unused dimensions. (Use Default) is not set for any dimension type. Inactive Scenario Types remain unchanged until they are ready to be activated.
After the Actual and Budget Scenario Types have data in them, due to following the recommended configuration, the user is able to change the UD4 Dimension assignment in the Budget Scenario Type to include the new summary customer dimension.
IMPORTANT: Once the new dimension type assignment is saved, the assignment is locked in. Changing from a Root dimension is a one-time change that cannot be reverted if there is data in the cube and Scenario Type combination.
Once the new dimension is added to the Budget Scenario Type, the user will see the history in UD4#None and that the new dimension members are active for input in subsequent budget cycles. Since it was assigned to the specific Budget Scenario Type instead of the (Default) Scenario Type, the new UD4 dimension is invalid for the Actual Scenario Type.
This configuration also enables the user to add UD4 and UD5 dimensions in the future by following the same steps.
NOTE: While this adds flexibility for the future, configuring the cube dimensions in this way does not enable you to change active dimensions with data.
Configuration 2: Dimension Assignment to the (Default) Scenario Type
It is not recommended for the user to assign all dimensions to the (Default) Scenario Type and only use additional Scenario Types for dimensions that differ. While this configuration works and enables the user to add additional dimensions in the future, it is much less flexible. Additional dimensions in this setup must be assigned to the (Default) Scenario Type and will apply to all active scenarios. For this use case, the Scenario Types are set to the following non-recommended configuration:
-
In the (Default) Scenario Type, Entity and Scenario dimension types are assigned. All active dimensions are also assigned to the (Default) Scenario Type.
-
In the Actual Scenario Type, all dimension types are left as (Use Default).
-
In the Budget Scenario Type, a different Account Dimension is added to enable the use of extensibility. All other dimension types are left as (Use Default).
With this configuration, the user will receive an error if they assign the new customer dimension to UD4 in the Budget Scenario Type. Because (Use Default) was left on all active Scenario Types, the user is now locked into whatever the (Default) Scenario Type has set for these dimensions, and they cannot be updated.
To add the new summary customer dimension, the user must assign it to the (Default) Scenario Type.
This assignment works for the Budget Scenario Type as required, but it is now active for the Actual Scenario Type, which may not be the desired result.
With this configuration, existing business rules and member formulas need to be validated throughout the application to ensure the right intersections are specified. Because this additional dimension contains valid intersections in all Scenario Types, rules need to be explicit in their filtering and writing of data. If rules are written improperly or too openly, this new dimension may impact performance and cause bad data to be calculated in these new intersections. Additionally, no input rules may be necessary to limit input to these intersections in Scenario Types that do not apply.
